1. Field of the Invention
The present invention relates generally to computer systems, and specifically, to a method and apparatus for providing a low-cost, efficient data streaming mechanism between two buses.
2. Background Information
In computer systems, bus bridges are typically used to separate a first bus from a second bus. This isolates transactions on the first bus from affecting transactions on the second bus, and vise versa. Moreover, the physical characteristics of a bus place a limit on the number of devices (or agents) that may be attached to it. Accordingly, many computer systems implement multiple-bus architectures having a number of physically separate buses to further expand functionality. The buses may be the same bus (protocol) or may be of different protocols. Thus, the bus bridge also interfaces one bus protocol to another, thereby allowing agents on the different buses to communicate.
A bus bridge that couples two buses together is typically transparent so that the physically separate buses may be treated by an agent and the system as on bus. To accomplish such a result, an address space is shared by agents on each bus. Read and write requests bearing an address range within the shared address space are generated by an initiator agent on an initiating bus. The bridge recognizes the address range and forwards the request to a target agent on a target bus. Thus, the bridge acts as the initiator on the target bus for the initiator agent on the initiating bus.
There is a myriad of bus and bridge architectures in the current state of computer technology. An example of a modern, computer bus is the Peripheral Components Interconnect (PCI) bus. The PCI bus is an industry standard, high performance, low latency system bus, generally defined by the PCI Special Interest Group (SIG) in PCI Local Bus Specification, Revision 2.1, Oct. 21, 1994. The PCI SIG also maintains a bridge architecture described in PCI-to-PCI Bridge Architecture Specification, Revision 1.0, Apr. 5, 1994.
Transactions are defined here as complete transfers of data between an initiator and a target, where the initiator and target are on different physical buses coupled by a bridge. When forwarding data from one bus to another, bridges typically implement data queues to hide the delay associated with requesting and obtaining access to the target bus for obtaining or forwarding the data. Each transaction is typically assigned a logical queue which is released when the transaction is completed.
The queue will typically be part of a memory or buffer that implements a First-In-First-Out (xe2x80x9cFIFOxe2x80x9d) data structure. The FIFO is a data structure from which items are taken out in the same order they were put in. Typically, the FIFO may be written to and read from simultaneously.
A transaction as defined herein involves a request from an initiator to read from or write to a given address range which is claimed by a target. If the request is accepted by the bridge, the transaction begins and an appropriate access is started. An access typically includes an idle phase for setup, an address phase during which address information for the particular request is exchanged, and a data phase during which data is exchanged.
Alternatively, the request may be denied by the bridge. In that case, the bridge issues a termination known as a retry signal to the initiator. This may occur if the assigned bridge queue has no data to transfer or is full (e.g., the queue is being used for another pending transaction). If the request is denied, the initiator may repeat the request to complete an ongoing transaction or attempt to start a new one.
Where the request is accepted and a first access is started, the access may be prematurely terminated by the initiator, the target, or the bridge, for various reasons. If this happens, the request may be repeated or a subsequent request may be issued by the initiator to complete the transaction and transfer all of the requested data. Splitting the transaction so that the desired data is transferred in multiple accesses, however, introduces increased overhead in the form of additional accesses having additional idle and address phases. The increased overhead can reduce throughput, where throughput is the amount of data transferred across the bridge per unit time, averaged over a given period. It would be desirable to have a technique that permits an increase in throughput so that the bridge may be tuned to the particular application.
FIG. 1 illustrates a block diagram of a portion of a conventional computer system having two buses separated by a bus bridge. As shown therein, a bus bridge 10 is coupled between first and second buses 30 and 40. Also coupled to the first bus 30 are a plurality of devices including agent 32 and memory 34. Similarly, coupled to bus 40 are a plurality of devices including agent 42 and memory 44. The bus bridge 10 includes first and second unidirectional data queues 12 and 14, bus interface 16 for interfacing with the first bus 30, and bus interface 18 for interfacing with the second bus 40. The unidirectional data queue 12 is used solely for data transfers from the bus 40 to the bus 30 (i.e., a read by agent 32 from a device on bus 40 or a write by agent 42 to a device on bus 30), which is referred to as an outbound direction. Conversely, the unidirectional data queue 14 is used solely for data transfers from the bus 30 to the bus 40 (i.e., a read by agent 42 from a device on bus 30 or a write by agent 32 to a device on bus 40), which is referred to as an inbound direction.
Read Transaction
For a read, agent 322 initiates a read transaction for data from memory 44. The bridge 10 decodes the address of the transaction and checks at the queue 12 to determine whether the queue 12 has any data. Initially, the data queue 12 is empty and, as a result, the bridge 10 retries the initiator agent 32 indicating that no data is available. The bridge 10 begins filling up the data queue 12 with read data. In the meantime, the initiator agent 32 retries the bridge 10. This time the bridge 10 has data and starts draining the data from the queue 12. There are three conditions where the data transfer is stopped. The first is where there is an error due to any event. The second is where agent 32 is completely satisfied. The third is where the data queue 12 becomes empty (i.e., and under-run condition). If there is an under-run condition, the bridge 10 disconnects the agent 32, The agent 32 then has to initiate a further transaction to retrieve the data from the beginning or from the point where the under-run condition occurred. As can be seen, this reduces the efficiency of the data transfer.
One technique to prevent the queue 12 from becoming empty involves including logic within the bridge 10 to reacquire the bus 40 to maintain data in the data queue 12. From a data movement point of view, this technique is effective. However, from a complexity and silicon point of view, this technique poses a problem. That is, the logic required to prevent the queue 12 from becoming empty is complex and out of proportion to the rest of the logic in the bridge 10. Another problem, is that since the data queue 12 is unidirectional, agent 42 on bus 40 is blocked from initiating any transactions. Moreover, agent 42 is blocked from placing write data in the data queue 12 because the data queue is being used by the read transaction. This further hampers performance.
Write Transaction
For a write, agent 32 initiates a write transaction targeted for memory 44. The bridge 10 decodes the address and indicates to agent 32 that it is ready to receive data (assuming that the queue 14 has sufficient space). As a result, data begins filling the data queue 14. The bridge 10 then initiates a transaction on the bus 40 to write data to memory 44. Once the bridge 10 gets control of bus 40, it transfers data from queue 14 to memory 44. Again, from the point of view of agent 32, this is efficient because its request is being serviced uninterrupted. However, from a system stand point, this technique causes a problem because both buses are tied up, preventing agents hanging off bus 40 from utilizing the bus 40.
Consequently, it is desirable to provide a method and apparatus which overcome the aforementioned drawbacks.
The present invention comprises a data streaming method and apparatus. In one embodiment, a data streaming method includes detecting a transaction on a first bus that is targeted to a second bus, claiming the transaction to begin filling data in a queue, initiating a further transaction on the second bus to commence draining data from the queue when the first queue is filled up to a threshold value, and terminating the further transaction on the second bus when the queue is substantially empty, while data is filling in the queue from the first bus. One or more subsequent transactions are initiated and terminated on the second bus, as necessary, to drain data from the queue to the second bus when the queue is filled up to the threshold value and/or until the transaction is completed. The second bus operates at a faster speed than the first bus.